Continued translation of official I2P documentation.
This time it is a little more free, so that the text is readable in Russian.
Table of contents:
Part 1: “Everything you wanted to know and were afraid to ask about I2P»
Part 2: Tunnel magic, NetDB and protocol juggling
Part 3: Digital Garlic
Inbound and outbound tunnels operate on similar principles. The tunnel gateway accumulates a number of messages from the tunnels, eventually generating a message to send to the tunnel. The gateway then pre-encrypts the data and routes it through the first hop. This peer and subsequent tunnel participants check if the message is a duplicate by adding another layer of encryption and forward it to the subsequent tunnel.
Ultimately, the message reaches the target, after which it is fully decrypted and processed by the target itself. The difference is that the tunnel creator for transit tunnels will be the target, and for transit tunnels an additional level of encryption. The creator of the outgoing tunnel is the gateway and pre-decrypts the message so that it reaches the recipient without being noticed by peers.
Selecting peers and connecting them in a specific sequence is very important to understanding how I2P remains anonymous and performant..).
While NetDB (Network Database) (see below) has its own criteria for selecting, querying and storing peer records, the tunnel initializer can use any peers, in any order and number of times in a single tunnel.
If data with minimal latency and maximum efficiency is available around the world, then the customer's needs will be met based on his requirements, taking into account possible threats. Unfortunately, latency and throughput are not ideal and depend on peers being able to provide their bandwidth. The level of anonymity provided leaves its mark on the speed of the network..
Anonymity is ensured simply: peers are selected randomly from the entire network, requests to peers occur randomly and can last forever. Performance is ensured by selecting the fastest peers and distributing the load between them to ensure transparency and fault tolerance. They are also used to restore and rebuild tunnels when network capacity changes. Previously, everything was fragile and ineffective: there could be problems with access to information and insufficient anonymity was offered.
I2P offers a wide range of different sampling strategies, combined with anonymous peering based on profiles.
I2P uses permanent peer profiles that it generates by examining their work on the network, for example, if a peer responds to a search in netDB within 1.3 seconds, then information about the route and delays for both tunnels (incoming and outgoing) is recorded in its profile , which also records all requests and responses of the peer. The data obtained by measuring transport delays and congestion is not used as part of the peer profile, but is associated with specific routers.
While collecting information for profiles, the information will be systematized and as a result we will receive information about performance, latency, the peer’s ability to process large amounts of information, how loaded it is now and how well it is integrated into the network. These calculations are performed for each peer separately, and then the peers are compared with each other and sorted into categories: fast and capacious, high throughput, working not working.
The thresholds for allocation to these levels are generated dynamically, and although fairly simple algorithms are currently used for this, alternatives exist.
The following text describes very specific points, the term “harvesting attacks” denotes a type of attack that will allow you to create a list of users working with I2P. I would like someone to suggest a better equivalent, this option hurts my ears.
Deployment of a client tunnel is carried out through a simple and efficient random selection of peers, from the ones with the best capacity and speed. The selection of peers is carried out from netDB, the peers used for expansion have only some stability (not failing) and are used to transfer the “top of the hill” (the central point of the load - approx. lane). This type of operation provides very weak resistance to harvesting attacks. As a solution, the router may not load balance between peers, but mainly use only a separate channel, to reduce the impact of this attack, but makes the network less resistant to other types of threats.
Having received a random key, a route is generated using XOR. In the event of a harvesting attack, information is lost and the peer reports an error and then shuts down..
Another simple strategy to protect against harvesting is to simply regenerate the incoming tunnel, using new peers to create a new tunnel. To deal with the type of attack that targets clients, the outbound tunnel endpoints must remain unchanged. Of course, if peers as tunnel endpoints remain fixed, you need to set a connection time limit. A peer, as a tunnel endpoint, can simulate a temporary router failure, as a result the tunnel will be automatically recreated.
These two security strategies can be combined, using fixed participants and the XOR function to create tunnels. A more stringent security strategy implies precise (specific) connections between individual peers that are trusted and participate in creating the route under the same conditions (Reminiscent of Tor - approx. lane). The use of XOR implies the immutability of the order and the fact that the beginning and ending feast are always the same, and XOR only ensures the immutability of the order.
As mentioned earlier, I2P currently (release 0.8) includes a multi-level sampling strategy using XOR. A more detailed discussion of the mechanics of the tunnel, management and selection of peers can be found in the specificationtunnels.
As stated earlier I2P works by exchanging network metadata, this will be explained in more detail below.
A certain percentage of I2P users are designated as 'FloodFill'. Currently, machines on which I2P is installed have a fairly high throughput, so in the event of a sharp drop in the number of 'FloodFill' routers, the router (tautology) assigns itself to 'FloodFill'’.
Other routers may store information and lookup data that will be retrieved by querying fully populated routers. If the 'FloodFill' router receives a storage request, then the 'FloodFill' router starts forwarding this message to other 'FloodFill' routers using the algorithm Kademlia. Search requests are implemented differently to prevent security issues; when the search is completed, the 'FloodFill' router will not forward the result to anyone, but will respond if the data is requested.
The online database stores two types of information:
All this information will be signed by the “publishing party” and verified by any I2P router, and will also be saved by it. Also, the stored information contains timestamps in order to avoid storing outdated information and prevent some possible types of attacks.
Also some important notes:
If in this option a certain person wants to reach a certain recipient. It is possible this can be done without publishing the destination to netDb. However, you must then pass the address in another way. For example, in an encrypted alternative way leaseSets. This leaseSets can be decrypted by a person who has access to the decryption key.
NetDB self-configuring is quite simple. After a router manages to obtain at least one routerInfo from reachable peers, it can ask the peer for links to other routers on the network. Currently, users post their routerInfo information on websites to make it available to everyone. I2P automatically connects to one of these websites to collect routerInfo files and download them.
I2P network lookups do not occur via netDb in other routers. Currently this is not a big problem since the network is not very large. However, as the network grows, not all routerInfo and leaseSet files will be present on every netDb router. This will lead to a deterioration in the success rate of searches. Because of this, a fix to netDb will be made in future releases.
Communication between routers must ensure confidentiality and data integrity, while authentication and authentication must ensure that the router has contacted the person who should receive the message. The details of how the routers communicate with each other are not important, but we will look at 3 separate protocols that have been used in various nodes to meet these needs.”.
The history of I2P began on the basis of the TCP protocol, which later fell into disuse. Then, to meet the high demand for good quality communications (the number of routers eventually only increased), I2P switched from a TCP-based protocol to a UDP-based protocol - "Secure Semireliable UDP" or "SSU"».
As described in the SSU specification:
The purpose of this protocol is to provide secure authentication, reliable and out-of-order delivery of messages, leaving a minimum amount of data that can be viewed by third parties. It should provide high quality communications as well as TCP-friendly load control and may include PMTU detection. It must be able to efficiently move large amounts of data at speeds sufficient for home users. In addition, it must support the ability to separate the network, as most NAT or firewalls do.
After the introduction of SSU, network congestion problems were solved by the new NIO-based TCP, which allowed the inclusion of the NTCP protocol. It is enabled by default for outgoing connections. If you configure NAT/Firewall to allow incoming connections and specify the external host and port (DynDNS and etc), you can use /config.jsp to establish incoming connections. NTCP is based on NIO and does not suffer from the 1-stream limitation like older versions of the TCP protocol.
I2P supports different transport protocols. The required transport protocol for the outgoing connection is selected with a rate. Depending on the rate, priority is selected. The transport responds with a different rate, depending on whether there is an already established connection with the partner.
In most current implementation situations, NTCP has higher priority for establishing outgoing connections. SSU is enabled for both outgoing and incoming connections. Your firewall and I2P router must be configured correctly to establish an NTCP connection.
For more information see protocol NTCP.
This time it is a little more free, so that the text is readable in Russian.
Table of contents:
Part 1: “Everything you wanted to know and were afraid to ask about I2P»
Part 2: Tunnel magic, NetDB and protocol juggling
Part 3: Digital Garlic
Tunnels
Inbound and outbound tunnels operate on similar principles. The tunnel gateway accumulates a number of messages from the tunnels, eventually generating a message to send to the tunnel. The gateway then pre-encrypts the data and routes it through the first hop. This peer and subsequent tunnel participants check if the message is a duplicate by adding another layer of encryption and forward it to the subsequent tunnel.
Ultimately, the message reaches the target, after which it is fully decrypted and processed by the target itself. The difference is that the tunnel creator for transit tunnels will be the target, and for transit tunnels an additional level of encryption. The creator of the outgoing tunnel is the gateway and pre-decrypts the message so that it reaches the recipient without being noticed by peers.
Selecting peers and connecting them in a specific sequence is very important to understanding how I2P remains anonymous and performant..).
While NetDB (Network Database) (see below) has its own criteria for selecting, querying and storing peer records, the tunnel initializer can use any peers, in any order and number of times in a single tunnel.
If data with minimal latency and maximum efficiency is available around the world, then the customer's needs will be met based on his requirements, taking into account possible threats. Unfortunately, latency and throughput are not ideal and depend on peers being able to provide their bandwidth. The level of anonymity provided leaves its mark on the speed of the network..
Anonymity is ensured simply: peers are selected randomly from the entire network, requests to peers occur randomly and can last forever. Performance is ensured by selecting the fastest peers and distributing the load between them to ensure transparency and fault tolerance. They are also used to restore and rebuild tunnels when network capacity changes. Previously, everything was fragile and ineffective: there could be problems with access to information and insufficient anonymity was offered.
I2P offers a wide range of different sampling strategies, combined with anonymous peering based on profiles.
I2P uses permanent peer profiles that it generates by examining their work on the network, for example, if a peer responds to a search in netDB within 1.3 seconds, then information about the route and delays for both tunnels (incoming and outgoing) is recorded in its profile , which also records all requests and responses of the peer. The data obtained by measuring transport delays and congestion is not used as part of the peer profile, but is associated with specific routers.
While collecting information for profiles, the information will be systematized and as a result we will receive information about performance, latency, the peer’s ability to process large amounts of information, how loaded it is now and how well it is integrated into the network. These calculations are performed for each peer separately, and then the peers are compared with each other and sorted into categories: fast and capacious, high throughput, working not working.
The thresholds for allocation to these levels are generated dynamically, and although fairly simple algorithms are currently used for this, alternatives exist.
The following text describes very specific points, the term “harvesting attacks” denotes a type of attack that will allow you to create a list of users working with I2P. I would like someone to suggest a better equivalent, this option hurts my ears.
Deployment of a client tunnel is carried out through a simple and efficient random selection of peers, from the ones with the best capacity and speed. The selection of peers is carried out from netDB, the peers used for expansion have only some stability (not failing) and are used to transfer the “top of the hill” (the central point of the load - approx. lane). This type of operation provides very weak resistance to harvesting attacks. As a solution, the router may not load balance between peers, but mainly use only a separate channel, to reduce the impact of this attack, but makes the network less resistant to other types of threats.
Having received a random key, a route is generated using XOR. In the event of a harvesting attack, information is lost and the peer reports an error and then shuts down..
Another simple strategy to protect against harvesting is to simply regenerate the incoming tunnel, using new peers to create a new tunnel. To deal with the type of attack that targets clients, the outbound tunnel endpoints must remain unchanged. Of course, if peers as tunnel endpoints remain fixed, you need to set a connection time limit. A peer, as a tunnel endpoint, can simulate a temporary router failure, as a result the tunnel will be automatically recreated.
These two security strategies can be combined, using fixed participants and the XOR function to create tunnels. A more stringent security strategy implies precise (specific) connections between individual peers that are trusted and participate in creating the route under the same conditions (Reminiscent of Tor - approx. lane). The use of XOR implies the immutability of the order and the fact that the beginning and ending feast are always the same, and XOR only ensures the immutability of the order.
As mentioned earlier, I2P currently (release 0.8) includes a multi-level sampling strategy using XOR. A more detailed discussion of the mechanics of the tunnel, management and selection of peers can be found in the specificationtunnels.
Network Database
As stated earlier I2P works by exchanging network metadata, this will be explained in more detail below.
A certain percentage of I2P users are designated as 'FloodFill'. Currently, machines on which I2P is installed have a fairly high throughput, so in the event of a sharp drop in the number of 'FloodFill' routers, the router (tautology) assigns itself to 'FloodFill'’.
Other routers may store information and lookup data that will be retrieved by querying fully populated routers. If the 'FloodFill' router receives a storage request, then the 'FloodFill' router starts forwarding this message to other 'FloodFill' routers using the algorithm Kademlia. Search requests are implemented differently to prevent security issues; when the search is completed, the 'FloodFill' router will not forward the result to anyone, but will respond if the data is requested.
The online database stores two types of information:
- RouterInfo stores information about a specific I2P router and how you can contact it.
- leaseSet stores information about specific destinations (for example: I2P web server, e-mail server, etc.. ).
All this information will be signed by the “publishing party” and verified by any I2P router, and will also be saved by it. Also, the stored information contains timestamps in order to avoid storing outdated information and prevent some possible types of attacks.
Also some important notes:
Unpublished and encrypted leasesets:
If in this option a certain person wants to reach a certain recipient. It is possible this can be done without publishing the destination to netDb. However, you must then pass the address in another way. For example, in an encrypted alternative way leaseSets. This leaseSets can be decrypted by a person who has access to the decryption key.
Self-tuning:
NetDB self-configuring is quite simple. After a router manages to obtain at least one routerInfo from reachable peers, it can ask the peer for links to other routers on the network. Currently, users post their routerInfo information on websites to make it available to everyone. I2P automatically connects to one of these websites to collect routerInfo files and download them.
Search scalability:
I2P network lookups do not occur via netDb in other routers. Currently this is not a big problem since the network is not very large. However, as the network grows, not all routerInfo and leaseSet files will be present on every netDb router. This will lead to a deterioration in the success rate of searches. Because of this, a fix to netDb will be made in future releases.
Transport protocol
Communication between routers must ensure confidentiality and data integrity, while authentication and authentication must ensure that the router has contacted the person who should receive the message. The details of how the routers communicate with each other are not important, but we will look at 3 separate protocols that have been used in various nodes to meet these needs.”.
The history of I2P began on the basis of the TCP protocol, which later fell into disuse. Then, to meet the high demand for good quality communications (the number of routers eventually only increased), I2P switched from a TCP-based protocol to a UDP-based protocol - "Secure Semireliable UDP" or "SSU"».
As described in the SSU specification:
The purpose of this protocol is to provide secure authentication, reliable and out-of-order delivery of messages, leaving a minimum amount of data that can be viewed by third parties. It should provide high quality communications as well as TCP-friendly load control and may include PMTU detection. It must be able to efficiently move large amounts of data at speeds sufficient for home users. In addition, it must support the ability to separate the network, as most NAT or firewalls do.
After the introduction of SSU, network congestion problems were solved by the new NIO-based TCP, which allowed the inclusion of the NTCP protocol. It is enabled by default for outgoing connections. If you configure NAT/Firewall to allow incoming connections and specify the external host and port (DynDNS and etc), you can use /config.jsp to establish incoming connections. NTCP is based on NIO and does not suffer from the 1-stream limitation like older versions of the TCP protocol.
I2P supports different transport protocols. The required transport protocol for the outgoing connection is selected with a rate. Depending on the rate, priority is selected. The transport responds with a different rate, depending on whether there is an already established connection with the partner.
In most current implementation situations, NTCP has higher priority for establishing outgoing connections. SSU is enabled for both outgoing and incoming connections. Your firewall and I2P router must be configured correctly to establish an NTCP connection.
For more information see protocol NTCP.
